Control Flow Based Pointcuts for Security Hardening Concerns

In this paper, we present two new control flow based pointcuts to Aspect-Oriented Programming (AOP) languages that are needed for systematic hardening of security concerns. They allow to identify particular join points in a program’s control flow graph (CFG). The first proposed primitive is the GAFlow, the closest guaranteed ancestor, which returns the closest ancestor join point to the pointcuts of interest that is on all their runtime paths. The second proposed primitive is the GDFlow, the closest guaranteed descendant, which returns the closest child join point that can be reached by all paths starting from the pointcuts of interest. We find these pointcuts to be necessary because they are needed to perform many security hardening practices and, to the best of our knowledge, none of the existing pointcuts can provide their functionalities. Moreover, we show the viability and correctness of our proposed pointcuts by elaborating and implementing their algorithms and presenting the results of a testing case study. 1 Motivations & Background In today’s computing world, security takes an increasingly predominant role. The industry is facing challenges in public confidence at the discovery of vulnerabilities, and customers are expecting security to be delivered out of the box, even on programs that were not designed with security in mind. The challenge is even greater when legacy systems must be adapted to networked/web environments, while they are not originally designed to fit into such high-risk environments. Tools and guidelines have been available for developers for a few years already, but their practical adoption is limited so far. Software maintainers must face the challenge to improve program security and are often underequipped to do so. In some cases, little can be done to improve the situation, ∗ This research is the result of a fruitful collaboration between CSL (Computer Security Laboratory) of Concordia University, DRDC (Defence Research and Development Canada) Valcartier and Bell Canada under the NSERC DND Research Partnership Program. 2 Laverdière, Mourad, Soeanu, Debbabi especially for Commercial-Off-The-Shelf (COTS) software products that are no longer supported, or for in-house programs for which their source code is lost. However, whenever the source code is available, as it is the case for Free and Open-Source Software (FOSS), a wide range of security improvements could be applied once a focus on security is decided. Very few concepts and approaches emerged in the literature to help and guide developers to harden security into software. In this context, AOP appears to be a promising paradigm for software security hardening, which is an issue that has not been adequately addressed by previous programming models such as object-oriented programming (OOP). It is based on the idea that computer systems are better programmed by separately specifying the various concerns, and then relying on underlying infrastructure to compose them together. The techniques in this paradigm were precisely introduced to address the development problems that are inherent to crosscutting concerns. Aspects allow us to precisely and selectively define and integrate security objects, methods and events within application, which make them interesting solutions for many security issues [3, 5, 9, 16, 17]. However, AOP was not initially designed to address security issues, which resulted in many shortcomings in the current technologies [11, 7]. We were not able to apply some security hardening activities due to missing features. Such limitations forced us, when applying security hardening practices, to perform programming gymnastics, resulting in additional modules that must be integrated within the application, at a definitive runtime, memory and development cost. Moreover, the resulting code after applying this strategy of coding is of higher level of complexity as regards to auditing and evaluation. The specification of new security-related pointcuts is becoming a very challenging and interesting domain of research [14, 4, 10]. Pointcuts are used in order to specify where code should be injected, and can informally be defined as a subset of the points in a programs’ execution flow. In this context, we propose in this paper AOP pointcuts that are needed for security hardening concerns and allow one to identify join points in a program’s control flow graph (CFG). The proposed primitives are GAFlow, and GDFlow. GAFlow returns the closest ancestor join point to the pointcuts of interest that is on all their runtime paths. GDFlow returns the closest child join point that can be reached by all paths starting from the pointcuts of interest. These poincuts are needed to develop many security hardening solutions. Moreover, we combined all the deployed and proposed pointcuts in the literature, and, as far as we know, were not able to find a method that would isolate a single node in our CFG that satisfies the criteria we define for GAFlow and GDFlow. This paper is organized as follows: we first cast a quick glance at security hardening and the problem that we address in Section 2. In Sections 3 and 4 we show the usefulness of our proposal and its advantages. Afterwards, in Section 5, we describe and specify the GAFlow and GDFlow pointcuts. In Section 6, we present the algorithms necessary for implementing the proposed pointcuts, together with the required hierarchical graph labeling method. This section also Control Flow Based Pointcuts for Security Hardening Concerns 3 shows the results of our implementation in a case study. We move on to the related work in Section 7, and then conclude in Section 8. 2 Security Hardening In our prior work [12], we proposed that software security hardening be defined as any process, methodology, product or combination thereof that is used to add security functionalities and/or remove vulnerabilities or prevent their exploitation in existing software. This definition focuses on the solving of vulnerabilities, not on their detection. In this context, the following constitutes the classification of security hardening methods: Code-Level Hardening Changes in the source code in a way that prevents vulnerabilities without altering the design. For example, we can add boundchecking on array operations, and use bounded string operations. Software Process Hardening Addition of security features in the software build process without changes in the original source code. For instance, the use of compiler-generated canary words and compiler options against double-freeing of memory would be considered as Software Process Hardening. Design-Level Hardening Re-engineering of the application in order to integrate security features that were absent or insufficient. Design-level changes would be, for example, adding an access control feature, changing communication protocol, or replacing temporary files with interprocess communication mechanisms. Operating Environment Hardening Improvements to the security of the execution context (network, operating systems, libraries, utilities, etc.) that is relied upon by the software. Examples would be deploying libsafe, using hardened memory managers and enabling security features of middleware. Security hardening practices are usually applied manually by injecting security code into the software [2, 8, 15, 18]. This task requires from the security architects to have a deep knowledge of the code inner working of the software, which is not available all the time. In this context, we elaborated in [13] an approach based on aspect orientation to perform security hardening in a systematic and automatic way. The primary objective of this approach is to allow the security architects to perform security hardening of software by applying proven solutions so far and without the need to have expertise in the low-level security solution domain. At the same time, the security hardening is applied in an organized and systematic way in order not to alter the original functionalities of the software. This is done by providing an abstraction over the actions required to improve the security of the program and adopting AOP to build our solutions. The result of our experimental results explored the usefulness of AOP to reach the objective of having systematic security hardening. During our work, we have developed security hardening solutions to secure connections in a 4 Laverdière, Mourad, Soeanu, Debbabi client-server application, added access control features to a program, encrypted memory contents for protection and corrected some low-level security issues in C programs. On the other hand, we have also concluded the shortcomings of the available AOP technologies in security and the need to elaborate new pointcuts for security hardening concerns. 3 Usefulness of GAFlow and GDFlow for Security Hardening Many security hardening practices require the injection of code around a set of join points or possible execution paths [2, 8, 15, 18]. Examples of such cases would be the injection of security library initialization/deinitialization, privilege level changes, atomicity guarantee, logging, etc. The current AOP models only allow us to identify a set join points in the program, and therefore inject code before, after and/or around each one of them. However, to the best of our knowledge, none of the current pointcuts enable the identification a join point common to a set of other join points where we can inject the code once for all of them. In the sequel, we present briefly the necessity and usefulness of our proposed pointcuts for some security hardening activities. 3.1 Security Library Initialization/Deinitialization In the case of security library initialization (e.g. access control, authorization, cryptography, etc.), our primitives allow us to initialize the needed library only for the branches of code where they are needed by identifying their GAFlow and/or GDFlow. Having both primitives would also avoid the need to keep global state variables about the current state of library initialization. We use as example part of an aspect that we elaborated for securing the connections of a client application. With the current AOP pointcuts, the aspect targets the main as the location for the TLS library initialization and deinitialization as depicted in Listing 1. Another possible solution could be the loading and unloading of the library before and after its use, which may cause runtime problems since api-specific data structures could be needed for other functions. However, in the case of large applications, especially for embedded ones, the two solutions create an accumulation of code injection statements that would create a significant, and possibly useless, waste of system resources. In listing 2, we see an improved aspect that would yield to more efficient and wider applicable result using the proposed pointcuts. Listing 1. Excerpt of Hardening Aspect for Securing Connections Using GnuTLS advice execution ("%␣␣main␣(...)␣") : around () { hardening_socketInfoStorageInit ();hardening_initGnuTLSSubsystem(NONE); tjp -> proceed (); hardening_deinitGnuTLSSubsystem ();hardening_socketInfoStorageDeinit (); *tjp -> result () = 0; } Control Flow Based Pointcuts for Security Hardening Concerns 5 Listing 2. Excerpt of Improved Hardening Aspect for Securing Connections Using